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DETAILED ACTION 



1 



This action is in response to the application filed on 04/23/200. 



Claim Rejections - 35 USC § 112 



2. The following is a quotation of the second paragraph of 35 U.S.C 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

3. Claim 3 and 16 are rejected under 35 USC. 1 12, second paragraph, as being indefinite 
for failing to particularly point out and distinctly claim the subject matter which applicant 
regards as the invention. 

4. As per Claim 3, "The method of Claim 3" is not cleared. The Examiner interprets is as 
"The method of Claim 1". 



5. Claiml6 is objected to because of the following informalities: 

6. As per Claim 16, "The system of claim 12" is miss-spelled. The Examiner interprets is as 
"The system of Claim 15".. Appropriate correction is required. 



(e) the invention was described in (1) an application for patent, published under section 122(b), by another filed 
in the United States before the invention by the applicant for patent or (2) a patent granted on an application for 
patent by another filed in the United States before the invention by the applicant for patent, except that an 
international application filed under the treaty defined in section 35 1 (a) shall have the effects for purposes of this 
subsection of an application filed in the United States only if the international application designated the United 
States and was published under Article 21(2) of such treaty in the English language. 



Specification 



Claim Rejections - 35 USC §102 
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7. Claims 7-9 are rejected under 35 U.S.C. 102(e) as being anticipated by Lection et al. (US 
Patent No. 6,418,446) hereafter Lection. 



8. As Per Claim 7, Lection disclosed: 

A method for outputting data from an application running on a computer system, the 
data output as Extensible Markup Language, the method comprising: 

-establishing a relationship of the output data and one or more Extensible Markup 
Language Document Object Model contexts; (see Column 3, Lines 8-10, "It is another object of 
the present invention to provide this technique using a DOM tree created from an XML syntax 
representation of the source data,"). 

-building a Document Object Model instance with the one or more contexts; (see 
Column 3, Lines 10-12, "creating an output DOM tree in which the destination data gathered 
from the source is reformatted and stored.") and (see Column 3, Lines 34-39, "This technique 
comprises: providing an input data source comprising one or more records, wherein each of the 
records has this dynamically variable record format, and wherein the dynamically variable record 
format of each record comprises a plurality of dynamically variable fields;") and (see Column 3, 
Lines 52-56, "Optionally, the first DOM tree may be created by parsing an Extended Markup 
Language (XML) representation of the selected record and the second DOM tree may be created 
by parsing an XML representation of the gather verb specification.") and 

-outputting the data from the Document Object Model instance as Extensible Markup 
Language, (see Column 3, Lines 48-52, "The selected record may be formatted as a first 
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Document Object Model (DOM) tree, the gather verb specification may be formatted as a second 
DOM tree, and the output data destination may be formatted as a third DOM tree ."). 

9. As Per Claim 8, the rejection of claims 7 is incorporated and further Lection disclosed: 

-activating plural contexts simultaneously to buffer data for output as a complete 
Document Object Model instance, (see Column 3, Lines 34-39, "This technique comprises: 
providing an input data source comprising one or more records, wherein each of the records has 
this dynamically variable record format, and wherein the dynamically variable record format of 
each record comprises a plurality of dynamically variable fields;") and (see Column 3, Lines 52- 
56, "Optionally, the first DOM tree may be created by parsing an Extended Markup Language 
(XML) representation of the selected record and the second DOM tree may be created by parsing 
an XML representation of the gather verb specification.") 

10. As Per Claim 9, the rejection of claims 8 is incorporated and further Lection disclosed: 
-creating a node for an output data; and ensuring the correct cardinality of the created 

node, (see Column 3, Lines 48-52, "The selected record may be formatted as a first Document 
Object Model (DOM) tree, the gather verb specification may be formatted as a second DOM 
tree, and the output data destination may be formatted as a third DOM tree."). 



11. Claims 23-25 are rejected under 35 U.S.C. 102(e) as being anticipated by Stefaniak (US 
Patent No. 6,550,054). 



p I 



'k 
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12. As Per Claim 23, Stefaniak disclosed: 

A method for modeling a legacy computer system comprising: 

-identifying incidents of applications of the legacy computer system that output data; 
(see Column 1, Lines 41-47, "An object of the present invention is to provide a method for 
reading and interpreting terminal-based screen applications in order to generate extensible 
Markup Language Metadata Interchange (XMI) representation of the UML. Another object of 
the present invention is to provide a method for capturing and recording screen relationships and 
dependencies"). 

-associating the incidents with an Extensible Markup Language schema; (see Column 
2, Lines 48-51, "FIG. 9 is a diagram that illustrates a UML modeling tool user interface that 
graphically displays a legacy program by interpreting an XML file in accordance with the 
present invention."), and 

-defining a control flow graph of the output incidents; (see FIG. 3, Column 2, Lines 29- 
30, "FIG. 3 is a diagram that shows an end to end process flow from a legacy program to a UML 
model.") and 

-creating a specification to modify the legacy computer system applications to provide 
output from a Document Object Model instance as Extensible Markup Language, (see Column 
2, Lines 39-45, "Referring now to FIG. 3, a diagram that shows an end-to-end process flow from 
a legacy program to an XML/UML file is shown. The process flow begins with any terminal 




Application/Control Number: 09/840,727 



Page 6 



Art Unit: 2122 

based legacy application 30, which produces application terminal screens 31. The terminal 
screens are discovered using the transform navigator 19, which produces application and screen 
specifications 32 "). 

13. As Per Claim 24, the rejection of claims 23 is incorporated and further Stefaniak 



-automatically modifying the legacy computer system applications in accordance with 
the specification.^^ Column 1, Lines 58-67, "These and other objects, which will become 
apparent as the invention is described in detail below, are provided in a computer-implemented 
method that automatically converts text-based screen applications of a legacy computer system 
into a graphical-based representation thereof The method includes the steps of transforming a 
terminal-based screen application into an application specification; converting the application 
specification into a modeling language-based representation; and, displaying the modeling 
language-based representation with a graphical user interface."). 

14. As Per Claim 25, Stefaniak disclosed:^ system for modeling an output application of a 
legacy computer system comprising: 

-a modeling engine interfaced with the legacy computer system, the modeling engine 
operable to analyze an application loaded on the legacy computer system to identify incidents 
within the application that output data from the legacy computer system; (see Column 1, Lines 
41-47, "An object of the present invention is to provide a method for reading and interpreting 



disclosed: 
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terminal-based screen applications in order to generate extensible Markup Language Metadata 
Interchange (XMI) representation of the UML. Another object of the present invention is to 
provide a method for capturing and recording screen relationships and dependencies") and (see 
Column 1, Lines 58-67, "These and other objects, which will become apparent as the invention is 
described in detail below, are provided in a computer-implemented method that automatically 
converts text-based screen applications of a legacy computer system into a graphical-based 
representation thereof The method includes the steps of transforming a terminal-based screen 
application into an application specification; converting the application specification into a 
modeling language-based representation; and, displaying the modeling language-based 
representation with a graphical user interface."). 

-a control flow graph of the output operations within the applications, the control flow 
graph having plural nodes, each node associated with an output incident; (see FIG. 3, Column 
2, Lines 29-30, "FIG. 3 is a diagram that shows an end to end process flow from a legacy 
program to a UML model. 7 ') and (see Column 5, Lines 39-57, "Referring now to FIG. 3, a 
diagram that shows an end-to-end process flow from a legacy program to an XML/UML file is 
shown. The process flow begins with any terminal based legacy application 30, which 
produces application terminal screens 31* The terminal screens are discovered using the 
transform navigator 19, which produces application and screen specifications 32. The application 
and screen specifications 32 are then applied to the file warehouse 21, which produces the 
project file reference model 27. The model 27 is applied to the terminal-to-XML 20, which 
produces a UML model 34 in a MOF compliant repository. The UML model is then applied to 
the UML model to XMI/UML DTD generator 22, which produces XMI/UML DTD streams 35. 




Application/Control Number: 09/840,727 



Page 8 



Art Unit: 2122 

The streams 35 may be used for several purposes, including transmitting legacy screen based 
application specifications over a network to modeling tools. From the modeling tools the 
application specifications could be viewed in an object oriented way compliant with the UML 
standard."), and 

-a graphical user interface in communication with the modeling engine, the graphical 
user interface operable to display the control flow graph and the incidents; wherein the 
graphical user interface maps the incidents of the applications with the control flow graph and 
an Extensible Markup Language schema, (see Column 1, Lines 58-67, "These and other 
objects, which will become apparent as the invention is described in detail below, are provided in 
a computer-implemented method that automatically converts text-based screen applications of a 
legacy computer system into a graphical-based representation thereof The method includes the 
steps of transforming a terminal-based screen application into an application specification; 
converting the application specification into a modeling language-based representation; and, 
displaying the modeling language-based representation with a graphical user interface."). 



15. The following is a quotation of 35 U.S. C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 



Claim Rejections - 35 USC §103 



P * m 
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16. Claims 1-2, 4-6, 20-21 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Stefaniak (US Patent No. 6,550,054) in view of van Elkeren et al. (US Patent No. 6,618,852) 
hereafter van Elkeren. 

1 7. As Per Claim 1, Stefaniak disclosed: A method for reporting data from a legacy 
computer system using Extensible Markup Language, the method comprising: 

-generating a model of the legacy computer system; (see Column 1, Lines 58-67, "These 
and other objects, which will become apparent as the invention is described in detail below, are 
provided in a computer-implemented method that automatically converts text-based screen 
applications of a legacy computer system into a graphical-based representation thereof. The 
method includes the steps of transforming a terminal-based screen application into an application 
specification; converting the application specification into a modeling language-based 
representation; and, displaying the modeling language-based representation with a graphical user 
interface."). 

-mapping the model of the legacy computer system to an Extensible Markup Language 
schema; (see Column 1, Line67 to column 2, lines 1-4 , "This method also includes the 
capability of generating document type definitions of the modeling language-based 
representation, which enables transmission of the representation among modeling tools."), 
"document type definitions" is XML schema, and 
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-automatically modifying one or more applications of the legacy computer system, (see 
Column 5, Lines 39-43, "Referring now to FIG. 3, a diagram that shows an end-to-end process 
flow from a legacy program to an XML/UML file is shown. The process flow begins with any 
terminal based legacy application 30, which produces application terminal screens 31") the 
modified application operable to output data written from the legacy computer system in 
Extensible Markup Language, (see Column 5, Lines 43-57, "The terminal screens are 
discovered using the transform navigator 19, which produces application and screen 
specifications 32. The application and screen specifications 32 are then applied to the file 
warehouse 21, which produces the project file reference model 27. The model 27 is applied to 
the terminal-to-XML 20, which produces a UML model 34 in a MOF compliant repository. The 
UML model is then applied to the UML model to XMI/UML DTD generator 22, which 
produces XML/UML DTD streams 35. The streams 35 may be used for several purposes, 
including transmitting legacy screen based application specifications over a network to 
modeling tools. From the modeling tools the application specifications could be viewed in an 
object oriented way compliant with the UML standard."). 

Stefaniak didn't explicitly disclose using a Document Object Model. However, van 
Elkeren taught automatically modifying one or more applications of the legacy computer 
system, the modified application operable to output data written using a Document Object 
Model from the legacy computer system in Extensible Markup Language, (see Column 12, 
Lines 5-10, "Preferably, a standard API, the XML DOM (Document Object Model) is used to 
access and manipulate XML data. The DOM provides a standard set of properties, methods, and 
events for program developers to use. This set of standards, the object model, provides a simple 
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means of reading and writing data to and from an XML tree structure.")- Therefore, it would 
have been obvious to one of ordinary skill in the art at the time the invention was made to use 
DOM, as suggested by van Elkeren, to apply to output XML data. The modification would have 
been obvious because one of ordinary skill in the art would have been motivated to provide a 
simple means of reading and writing data to and from an XML tree structure. 



18. As Per Claim 2, the rejection of claim 1 is incorporated and further Stefaniak disclosed: 

-providing the legacy computer system with a writer engine, the writer engine having 
the Extensible Markup Language Schema loaded as a data file; (see Column 1, Line67 to 
column 2, lines 1-4 , "This method also includes the capability of generating document type 
definitions of the modeling language-based representation, which enables transmission of the 
representation among modeling tools."), "document type definitions" is XML schema, and 

Stefaniak didn't explicitly disclose populating a Document Object Model. However, van 
Elkeren taught calling the writer engine with the modified applications, the writer engine 
populating the Document Object Model according to the Extensible Markup Language 
schema by building a Document Object Model instance with one or more contexts, (see 
Column 12, Lines 5-10, "Preferably, a standard API, the XML DOM (Document Object Model) 
is used to access and manipulate XML data. The DOM provides a standard set of properties, 
methods, and events for program developers to use. This set of standards, the object model, 
provides a simple means of reading and writing data to and from an XML tree structure."). 
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention 
was made to populate DOM, as suggested by van Elkeren, to apply to output XML data. The 
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modification would have been obvious because one of ordinary skill in the art would have been 
motivated to provide a simple means of reading and writing data to and from an XML tree 
structure. 



19. As Per Claim 4, Stefaniak disclosed: A system for reporting data from a legacy 
computer system in an Extensible Markup Language format, the system comprising: 

-a modeling engine in communication with the legacy computer system, the modeling 
engine operable to generate a model of reported data written by an application residing on the 
legacy computer system; (see Column 1, Lines 58-67, "These and other objects, which will 
become apparent as the invention is described in detail below, are provided in a computer- 
implemented method that automatically converts text-based screen applications of a legacy 
computer system into a graphical-based representation thereof The method includes the steps 
of transforming a terminal-based screen application into an application specification; converting 
the application specification into a modeling language-based representation; and, displaying the 
modeling language-based representation with a graphical user interface.' 5 ). 

-a mapping engine in communication with the modeling engine, the mapping engine 
operable to generate a modification specification by mapping the model to an Extensible 
Markup Language schema; (see Column 5, Lines 43-57, "The terminal screens are discovered 
using the transform navigator 19, which produces application and screen specifications 32. The 
application and screen specifications 32 are then applied to the file warehouse 21, which 
produces the project file reference model 27. The model 27 is applied to the terminal-to-XML 




• 
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20, which produces a UML model 34 in a MOF compliant repository. The UML model is then 
applied to the UML model to XMI/UML DTD generator 22, which produces XMI/UML DTD 
streams 35. The streams 35 may be used for several purposes, including transmitting legacy 
screen based application specifications over a network to modeling tools. From the modeling 
tools the application specifications could be viewed in an object oriented way compliant with the 
UML standard.")- and 

-a code generation engine in communication with the mapping engine and the legacy 
computer system, the code generation engine operable to modify legacy computer system 
application code to directly output data from Extensible Markup Language, (see Column 5, 
Lines 43-57, "The terminal screens are discovered using the transform navigator 19, which 
produces application and screen specifications 32. The application and screen specifications 32 
are then applied to the file warehouse 21, which produces the project file reference model 27. 
The model 27 is applied to the terminal-to-XML 20, which produces a UML model 34 in a MOF 
compliant repository. The UML model is then applied to the UML model to XMI/UML DTD 
generator 22, which produces XMI/UML DTD streams 35. The streams 35 may be used for 
several purposes, including transmitting legacy screen based application specifications over a 
network to modeling tools. From the modeling tools the application specifications could be 
viewed in an object oriented way compliant with the UML standard."). 

Stefaniak didn't explicitly disclose using a Document Object Model. However, van 
Elkeren taught a code generation engine in communication with the mapping engine and the 
legacy computer system, the code generation engine operable to modify legacy computer 
system application code to directly output data from a Document Object Model as Extensible 
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Markup Language, (see Column 12, Lines 5-10, "Preferably, a standard API, the XML DOM 
(Document Object Model) is used to access and manipulate XML data. The DOM provides a 
standard set of properties, methods, and events for program developers to use. This set of 
standards, the object model, provides a simple means of reading and writing data to and from an 
XML tree structure."). Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to use DOM, as suggested by van Elkeren, to apply to output 
XML data. The modification would have been obvious because one of ordinary skill in the art 
would have been motivated to provide a simple means of reading and writing data to and from an 
XML tree structure. 



20. As Per Claim 5, the rejection of claim 4 is incorporated and further Stefaniak disclosed: 

-a context table associated with the legacy computer system, the context table providing 
the Extensible Markup Language schema to the legacy computer system; and 

-a writer engine loaded on the legacy computer system and having the Extensible 
Markup Language schema stored as a data file, the writer engine communicating with the 
modified legacy computer system applications to buffer data in plural contexts for output as 
Extensible Markup Language, (see Column 6, Lines 41-58, "Referring now to FIG. 5C, at the 
connector C, a UML attribute and a UML datatype tag are assigned for each field name 
associated with the screen (block 65). Next, all the operations of the screen are initialized and 
transmitted as the operations of the UML class created for that screen (block 66). This is 
followed by making an inquiry whether or not there are any more screens in the UML package 
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(block 67). If the answer to this enquiry is yes, then a return is make back to block 62 (FIG. 
5B) as denoted by a connector E. If on the other hand, the answer to the above inquiry is no 
then a further inquiry is made to determine whether or not there are any more UML packages 
(block 68). If the answer to this inquiry is yes, then a return is made back to the block 61 
(FIG. 5B) as denoted by a connector D. If on the other hand, the answer to the above inquiry is 
no, then a step of saving the tempfile as tempfile.txt is executed (block 69). After this, the 
process ends (bubble 70)."). 

Stefaniak didn't explicitly disclose using a Document Object Model. However, van 
Elkeren taught a writer engine loaded on the legacy computer system and having the 
Extensible Markup Language schema stored as a data file, the writer engine communicating 
with the modified legacy computer system applications to buffer data in plural contexts within 
a Document Object Model for output as Extensible Markup Language, (see Column 12, Lines 
5-10, "Preferably, a standard API, the XML DOM (Document Object Model) is used to access 
and manipulate XML data. The DOM provides a standard set of properties, methods, and events 
for program developers to use. This set of standards, the object model, provides a simple means 
of reading and writing data to and from an XML tree structure."). Therefore, it would have been 
obvious to one of ordinary skill in the art at the time the invention was made to use DOM, as 
suggested by van Elkeren, to apply to output XML data. The modification would have been 
obvious because one of ordinary skill in the art would have been motivated to provide a simple 
means of reading and writing data to and from an XML tree structure. 



21. As Per Claim 6, the rejection of claim 5 is incorporated and further Stefaniak disclosed: 
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- the writer engine is coded in the computer language of the legacy computer system 
(see Column 6, Lines 41-58, "Referring now to FIG. 5C, at the connector C, a UML attribute and 
a UML datatype tag are assigned for each field name associated with the screen (block 65). Next, 
all the operations of the screen are initialized and transmitted as the operations of the UML class 
created for that screen (block 66). This is followed by making an inquiry whether or not there are 
any more screens in the UML package (block 67). If the answer to this enquiry is yes, then a 
return is make back to block 62 (FIG. 5B) as denoted by a connector £. If on the other hand, 
the answer to the above inquiry is no then a further inquiry is made to determine whether or not 
there are any more UML packages (block 68). If the answer to this inquiry is yes, then a 
return is made back to the block 61 (FIG. 5B) as denoted by a connector D. If on the other 
hand, the answer to the above inquiry is no, then a step of saving the tempfile as tempfile.txt is 
executed (block 69). After this, the process ends (bubble 70).") and (see Column 8, Lines 52-55, 
"when the program code is loaded into and executed by a machine, such as a computer, the 
machine becomes an apparatus for practicing the invention "). 

22. As Per Claim 20, Stefaniak disclosed: A method for outputting data from a legacy 
computer system from a DOM instance as Extensible Markup Language, the method 
comprising: 

-modifying an application of the legacy computer system to output data having a 
schema element; (see Fig. 6). 

-generating data from the modified application; (see Column 2, Lines 33-36, "FIGS. 5 A 
through 5C is a combined flow chart of the method for generating an UML/XML representation 
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of the file reference model created by the method described with reference to FIG. 4 above ") 
and (see Column 6, Lines 56-57, "the answer to the above inquiry is no, then a step of saving the 
tempfile as tempfile.txt is executed (block 69)."). 

- aligning the schema element and the current context; (see Column 6, Lines 25-33, 
"Referring now to FIG. 5B at the connector A, an inquiry is made as to whether or not there are 
any more sub-projects in the file reference model of the project (diamond 58). If the answer to 
this inquiry is yes, then a return is made back to the block 52 (FIG. 5A) as denoted by a 
connector B. On the other hand, if the answer to this inquiry is no, then a command to create a 
"tempfile" is executed (block 59). Next the project name of the file reference model is tagged to 
this tempfile as a UML model name (block 60)."). 

-writing the output data schema element to a current one of plural contexts of an 
Extensible Markup Language schema; (see Column 6, Lines 59-67 to Column 7, Lines 1-4, 
"Referring now to FIG. 6 where a flowchart depicting the process of generating an XML file 
representation of the UML model created by the process described in FIG. 5A through 5C. The 
process begins with a start bubble 72, followed by a process of parsing the tempfile (block 73) 
for the UML model created in FIGS. 5 A, 5B and 5C. Next, a call 74 is made to the various UML 
methods to build a model in memory. This is followed by a step 75 of reading the UML model 
from memory, created in the previous step, and building an XML file representation of the 
model Finally, the XML file representation created in the previous step is saved as 
<projectname.xml> (block 76) and the process ends (bubble 77)."). and 

Stefaniak didn't explicitly disclose using a Document Object Model. However, van 
Elkeren taught populating a Document Object Model with the data to output an Extensible 
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Markup Language instance, (see Column 12, Lines 5-10, "Preferably, a standard API, the XML 
DOM (Document Object Model) is used to access and manipulate XML data. The DOM 
provides a standard set of properties, methods, and events for program developers to use. This set 
of standards, the object model, provides a simple means of reading and writing data to and from 
an XML tree structure."). Therefore, it would have been obvious to one of ordinary skill in the 
art at the time the invention was made to use DOM, as suggested by van Elkeren, to apply to 
output XML data. The modification would have been obvious because one of ordinary skill in 
the art would have been motivated to provide a simple means of reading and writing data to and 
from an XML tree structure. 

23. As Per Claim 21, the rejection of claims 20 is incorporated and further Stefaniak disclose 
aligning the schema element further comprises: 

-determining that the schema element is a descendant of the current context; (see 
Column 6, Lines 25-33, "Referring now to FIG. 5B at the connector A, an inquiry is made as to 
whether or not there are any more sub-projects in the file reference model of the project 
(diamond 58). If the answer to this inquiry is yes, then a return is made back to the block 52 
(FIG. 5 A) as denoted by a connector B. On the other hand, if the answer to this inquiry is no, 
then a command to create a "tempfile" is executed (block 59). Next the project name of the file 
reference model is tagged to this tempfile as a UML model name (block 60)."). and 

-creating the Extensible Markup Language tags down through the schema element 

(see Column 6, Lines 34-40, "This step is followed by the step of tagging the file reference sub- 
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model name as a UML package name to the tempfile (block 61). Next, each screen specification 
in the UML package created in the previous step is parsed (block 62). Subsequently for each 
screen name, a UML class tag is assigned (block 63). The process illustration continues as 
denoted by a connector C ") 



24. Claims 10-14 are rejected under 35 U.S.C. 103(a) as being unpatentable over Lection et 
al. (US Patent No. 6,418,446) hereafter Lection in view of Stefaniak (US Patent No. 6,550,054). 

25. As Per Claim 10, the rejection of claims 7 is incorporated and further Lection disclosed: 
-generating output data with an application; (see Column 3, Lines 48-52, "The selected 

record may be formatted as a first Document Object Model (DOM) tree, the gather verb 
specification may be formatted as a second DOM tree, and the output data destination may be 
formatted as a third DOM tree.")- 

-outputting data from a Document Object Model instance from the writer engine 
according to the Extensible Markup Language schema, (see Column 3, Lines 8-12, "It is 
another object of the present invention to provide this technique using a DOM tree created from 
an XML syntax representation of the source data, and creating an output DOM tree in which 
the destination data gathered from the source is reformatted and stored."). 
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Lection didn't explicitly disclose using a writer engine. However, Stefaniak taught 
calling a writer engine with the application; providing the generated output data to the writer 
engine, (see Column 5, Lines 43-57, "The terminal screens are discovered using the transform 
navigator 19, which produces application and screen specifications 32. The application and 
screen specifications 32 are then applied to the file warehouse 21, which produces the project file 
reference model 27. The model 27 is applied to the terminal-to-XML 20, which produces a UML 
model 34 in a MOF compliant repository. The UML model is then applied to the UML model to 
XMI/UML DTD generator 22, which produces XMI/UML DTD streams 35. The streams 35 
may be used for several purposes, including transmitting legacy screen based application 
specifications over a network to modeling tools. From the modeling tools the application 
specifications could be viewed in an object oriented way compliant with the UML standard."). 
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention 
was made to incorporate XMI/UML DTD generator, as suggested by Stefaniak into the system 
of Lection, to produces XMI/UML DTD streams. The modification would have been obvious 
because one of ordinary skill in the art would have been motivated to provide a simple means to 
generate XML codes. 

26. As Per Claim 11, the rejection of claims 10 is incorporated and further Lection didn't 
explicitly disclose a legacy computer system application. However, Stefaniak teaches a legacy 
computer system application (see Column 1, Lines 58-67, "These and other objects, which will 
become apparent as the invention is described in detail below, are provided in a computer- 
implemented method that automatically converts text-based screen applications of a legacy 
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computer system into a graphical-based representation thereof. The method includes the steps 
of transforming a terminal-based screen application into an application specification; converting 
the application specification into a modeling language-based representation; and, displaying the 
modeling language-based representation with a graphical user interface ") Therefore, it would 
have been obvious to one of ordinary skill in the art at the time the invention was made to use 
legacy computer system, as suggested by Stefaniak , to build DOM instance of Lection. The 
modification would have been obvious because one of ordinary skill in the art would have been 
motivated to make application run on more computer systems. 

27. As Per Claim 12, the rejection of claims 1 1 is incorporated and further Lection didn't 
explicitly disclose the writer engine comprises an application run in the computer language of the 
legacy computer system application. However, Stefaniak teaches the writer engine comprises 
an application run in the computer language of the legacy computer system application (see 
Column 6, Lines 41-58, "Referring now to FIG. 5C, at the connector C, a UML attribute and a 
UML datatype tag are assigned for each field name associated with the screen (block 65). Next, 
all the operations of the screen are initialized and transmitted as the operations of the UML class 
created for that screen (block 66). This is followed by making an inquiry whether or not there are 
any more screens in the UML package (block 67). If the answer to this enquiry is yes, then a 
return is make back to block 62 (FIG. 5B) as denoted by a connector E. If on the other hand, 
the answer to the above inquiry is no then a further inquiry is made to determine whether or not 
there are any more UML packages (block 68). If the answer to this inquiry is yes, then a 
return is made back to the block 61 (FIG. 5B) as denoted by a connector D. If on the other 
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hand, the answer to the above inquiry is no, then a step of saving the tempfile as tempfile.txt is 
executed (block 69). After this, the process ends (bubble 70).") and (see Column 8, Lines 52-55, 
"when the program code is loaded into and executed by a machine, such as a computer, the 
machine becomes an apparatus for practicing the invention "). Therefore, it would have been 
obvious to one of ordinary skill in the art at the time the invention was made to use application in 
computer language, as suggested by Stefaniak, to run on legacy computer system. The 
modification would have been obvious because one of ordinary skill in the art would have been 
motivated to make application more flexible to run in different computer systems. 

28. As Per Claim 13, Lection disclosed: A system for outputting data from a Document 

Object Model as Extensible Markup Language, the system comprising: 

- a computer system having an application that outputs data; (see Column 3, Lines 48- 
52, "The selected record may be formatted as a first Document Object Model (DOM) tree, the 
gather verb specification may be formatted as a second DOM tree, and the output data 
destination may be formatted as a third DOM tree ")• 

Lection didn't explicitly disclose using a writer engine. However, Stefaniak taught a 
engine operable to write the output data in plural active contexts; wherein the application calls 
the writer engine when the application outputs data, the writer engine operable to build a 
Document Object Model instance for output of the data in accordance with the Extensible 
Markup Language schema, (see Column 5, Lines 43-57, "The terminal screens are discovered 
using the transform navigator 19, which produces application and screen specifications 32. The 
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application and screen specifications 32 are then applied to the file warehouse 21, which 
produces the project file reference model 27. The model 27 is applied to the terminal-to-XML 
20, which produces a UML model 34 in a MOF compliant repository. The UML model is then 
applied to the UML model to XMI/UML DTD generator 22, which produces XMI/UML DTD 
streams 35. The streams 35 may be used for several purposes, including transmitting legacy 
screen based application specifications over a network to modeling tools. From the modeling 
tools the application specifications could be viewed in an object oriented way compliant with the 
UML standard."). Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to incorporate XMLTJML DTD generator, as suggested by 
Stefaniak into the system of Lection, to produces XMI/UML DTD streams. The modification 
would have been obvious because one of ordinary skill in the art would have been motivated to 
provide a simple means to generate XML codes. 

As Per Claim 14, the rejection of claims 13 is incorporated and further Lection didn't 
explicitly disclose aligned element. However, Stefaniak taught the writer engine populates a 
Document Object Model as a schema element aligned with the current one of the contexts by 
creating Extensible Markup Language tagged nodes down through the schema element of the 
output data if the schema element of the output data is a descendant of the current context 
(see Column 6, Lines 25-33, "Referring now to FIG. 5B at the connector A, an inquiry is made 
as to whether or not there are any more sub-projects in the file reference model of the project 
(diamond 58). If the answer to this inquiry is yes, then a return is made back to the block 52 
(FIG. 5 A) as denoted by a connector B. On the other hand, if the answer to this inquiry is no, 



Application/Control Number: 09/840,727 Page 24 

Art Unit: 2122 

then a command to create a "tempfile" is executed (block 59). Next the project name of the file 
reference model is tagged to this tempfile as a UML model name (block 60) ") and (see Column 
6, Lines 41-58, "Referring now to FIG. 5C, at the connector C, a UML attribute and a UML 
datatype tag are assigned for each field name associated with the screen (block 65). Next, all 
the operations of the screen are initialized and transmitted as the operations of the UML class 
created for that screen (block 66). This is followed by making an inquiry whether or not there are 
any more screens in the UML package (block 67). If the answer to this enquiry is yes, then a 
return is make back to block 62 (FIG. 5B) as denoted by a connector E. If on the other hand, the 
answer to the above inquiry is no then a further inquiry is made to determine whether or not there 
are any more UML packages (block 68). If the answer to this inquiry is yes, then a return is made 
back to the block 61 (FIG. 5B) as denoted by a connector D. If on the other hand, the answer to 
the above inquiry is no, then a step of saving the tempfile as tempfile.txt is executed (block 69). 
After this, the process ends (bubble 70) "). Therefore, it would have been obvious to one of 
ordinary skill in the art at the time the invention was made to incorporate the teaching of 
Stefaniak into the system of Lection, to align the elementas. The modification would have been 
obvious because one of ordinary skill in the art would have been motivated to easily process the 
Preformatted documents. 

29. Claim 3 is rejected under 35 U.S.C. 103(a) as being unpatentable over Stefaniak (US 
Patent No. 6,550,054) in view of van Elkeren et al. (US Patent No. 6,618,852) hereafter van 
Elkeren further in view of Sandhu et al. (US Patent No. 6,347,307) hereafter Sandhu. 
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30. As Per Claim 3, the rejection of claim 1 is incorporated and further Stefaniak and van 
Elkeren taught written using a Document Object Model (see van Elkeren , Column 12, Lines 5- 
10, "Preferably, a standard API, the XML DOM (Document Object Model) is used to access and 
manipulate XML data. The DOM provides a standard set of properties, methods, and events for 
program developers to use. This set of standards, the object model, provides a simple means of 
reading and writing data to and from an XML tree structure.")- Stefaniak and van Elkeren didn't 
explicitly disclose applying XSLT stylesheets. However, Sandhu taught applying one or more 
XSLT stylesheets to restructure the Document Object Model instance for outputting data in a 
predetermined format, (see Column 50, Lines 24-30, "Next, the Connect Processor invokes a 
XSLT processor 1450--an off-the-shelf component (e.g., International Business Machines 
Corp.'s " Alphaworks")--to apply the rules of the XSL stylesheet 1440 to DOM tree 1430 (step 
1520). This process results in the generation of a FinXML document 1460 (step 1530) that can 
be used by the CFOWeb System."). Therefore, it would have been obvious to one of ordinary 
skill in the art at the time the invention was made to use XSLT stylesheets, as suggested by 
Sandhu, to apply to DOM. The modification would have been obvious because one of ordinary 
skill in the art would have been motivated to make the document usable by other computer 
system. 

31. Claims 15-18 are rejected under 35 U.S.C. 103(a) as being unpatentable over Lection et 
al. (US Patent No. 6,418,446) hereafter Lection in view of Stefaniak (US Patent No. 6,550,054) 
further in view of Shanmugasundaram et al. "Relational Databases for Querying XML 
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Documents: Limitations and Opportunities". Proceedings of the 25th VLDB Conference, 
Edinburgh, Scotland, 1999, hereafter Shanmugasundaram. 

32. As Per Claim IS, the rejection of claims 14 is incorporated and further Lection and 
Stefaniak didn't explicitly disclose traverse the Extensible Markup Language tagged nodes for 
the current context up to the minimal mutual ancestor. However, Shanmugasundaram taught the 
writer engine is further operable to determine a minimal mutual ancestor of the schema 
element and the current context and to traverse the Extensible Markup Language tagged 
nodes for the current context up to the minimal mutual ancestor and to create Extensible 
Markup Language tags for the schema element down from the mutual ancestor, (see page 5, 
left hand column last 2 lines to right hand column, lines 1-14, "Do a depth first traversal of the 
DTD graph, starting at the element node for which we are constructing relations. Each node is 
marked as "visited" the first time it is reached and is unmarked it once all its children have been 
traversed. If an unmarked node in the DTD graph is reached during depth first traversal, a new 
node bearing the same name is created in the element graph. In addition, a regular edge is 
created from the most recently created node in the element graph with the same name as the DFS 
parent of the current DTD node to the newly created node. If an attempt is made to traverse an 
already marked DTD node, then a backpointer edge is added from the most recently created node 
in the element graph to the most recently created node in the element graph with the same name 
as the marked DTD node "), and (see page 6, left hand column last 2 lines to right hand column 
first three lines, "Finally, of the mutually recursive elements all having indegree one (such as 
monograph and editor in Figure 8), one of them is made a separate relation. We can find such 
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mutually recursive elements by looking for strongly connected components in the DTD graph.")- 
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention 
was made to use traversed technique, as suggested by Sandhu, to construct DTD node. The 
modification would have been obvious because one of ordinary skill in the art would have been 
motivated to lookup node in DTD graph. 

33. As Per Claim 16, the rejection of claims 15 is incorporated and further Lection and 
Stefaniak disclose the computer system comprises a legacy computer system, (see Stefaniak , 
Column 1, Lines 58-67, "These and other objects, which will become apparent as the invention is 
described in detail below, are provided in a computer-implemented method that automatically 
converts text-based screen applications of a legacy computer system into a graphical-based 
representation thereof The method includes the steps of transforming a terminal-based screen 
application into an application specification; converting the application specification into a 
modeling language-based representation; and, displaying the modeling language-based 
representation with a graphical user interface."). 

34. As Per Claim 17, the rejection of claims 16 is incorporated and further Lection and 
Stefaniak disclose the application comprises a legacy computer system application modified to 
output an Extensible Markup Language schema element with output data, (see Stefaniak, 
Column 5, Lines 43-57, "The terminal screens are discovered using the transform navigator 19, 
which produces application and screen specifications 32. The application and screen 




# 



Application/Control Number: 09/840,727 



Page 28 



Art Unit: 2122 

specifications 32 are then applied to the file warehouse 21, which produces the project file 
reference model 27. The model 27 is applied to the terminal-to-XML 20, which produces a UML 
model 34 in a MOF compliant repository. The UML model is then applied to the UML model to 
XMFUML DTD generator 22, which produces XMI/UML DTD streams 35. The streams 35 
may be used for several purposes, including transmitting legacy screen based application 
specifications over a network to modeling tools. From the modeling tools the application 
specifications could be viewed in an object oriented way compliant with the UML standard."). 

35. As Per Claim 18, the rejection of claims 16 is incorporated and further Lection and 
Stefaniak disclose the writer engine is written in the code of the legacy computer system, (see 
Stefaniak , Column 6, Lines 41-58, "Referring now to FIG. 5C, at the connector C, a UML 
attribute and a UML datatype tag are assigned for each field name associated with the screen 
(block 65). Next, all the operations of the screen are initialized and transmitted as the operations 
of the UML class created for that screen (block 66). This is followed by making an inquiry 
whether or not there are any more screens in the UML package (block 67). If the answer to this 
enquiry is yes, then a return is make back to block 62 (FIG. 5B) as denoted by a connector 
E. If on the other hand, the answer to the above inquiry is no then a further inquiry is made to 
determine whether or not there are any more UML packages (block 68). If the answer to this 
inquiry is yes, then a return is made back to the block 61 (FIG. SB) as denoted by a 
connector D. If on the other hand, the answer to the above inquiry is no, then a step of saving 
the tempfile as tempfile.txt is executed (block 69). After this, the process ends (bubble 70).") and 
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(see Column 8, Lines 52-55, "when the program code is loaded into and executed by a 
machine, such as a computer, the machine becomes an apparatus for practicing the invention."). 



36. Claim 19 is rejected under 35 U.S.C. 103(a) as being unpatentable over Lection et al. (US 
Patent No. 6,418,446) hereafter Lection in view of Stefaniak (US Patent No. 6,550,054) further 
in view of Shanmugasundaram et al. "Relational Databases for Querying XML Documents: 
Limitations and Opportunities". Proceedings of the 25th VLDB Conference, Edinburgh, 
Scotland, 1999, hereafter Shanmugasundaram, further in view of Vermeire el al. (US Patent No. 
6,209,124) hereafter Vermeire. 

37. As Per Claim 19, the rejection of claims 18 is incorporated and further Lection, Stefaniak 
and Shanmugasundaram didn't explicitly disclose coboL However, Vermeire taught the code 
comprises COBOL, (see Column 18, Lines 18-21, "Alternatively, the XML document of Table 
20 could have been generated from COBOL source code which would have appeared as in 
Table 22."). Therefore, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made to use COBOL, as suggested by Vermeire, as the application language. 
The modification would have been obvious because one of ordinary skill in the art would have 
been motivated to utilizes a constructed intermediary acting with the host machine and its 
program applications, (see Column 5, Lines 7-17, "The invention utilizes a constructed 
intermediary which is user defined based upon the application language utilized by the host 
computer. The intermediary is further constructed to encompass the machine architecture and 



Application/Control Number: 09/840,727 Page 30 

Art Unit: 2122 

data structures involved in the host machine and application programs. This then allows the 
intermediary to function to restructure in-memory binary data streams received from the host 
into XML documents and to restructure XML documents into binary data streams capable of 
acting with the host machine and its program applications.")- 

38. Claim 22 is rejected under 35 U.S.C. 103(a) as being unpatentable over Stefaniak (US 
Patent No. 6,550,054) in view of van Elkeren et al. (US Patent No. 6,618,852) hereafter van 
Elkeren, further in view of Shanmugasundaram et al. "Relational Databases for Querying XML 
Documents: Limitations and Opportunities". Proceedings of the 25th VLDB Conference, 
Edinburgh, Scotland, 1999, hereafter Shanmugasundaram. 

39. As Per Claim 22, the rejection of claims 21 is incorporated and further Stefaniak and van 
Elkeren disclosed 

- determining a minimal mutual ancestor of the schema element and the current 
context; (see Stefaniak , Column 6, Lines 25-33, "Referring now to FIG. 5B at the connector A, 
an inquiry is made as to whether or not there are any more sub-projects in the file reference 
model of the project (diamond 58). If the answer to this inquiry is yes, then a return is made 
back to the block 52 (FIG. 5 A) as denoted by a connector B. On the other hand, if the answer to 
this inquiry is no, then a command to create a "tempfile" is executed (block 59). Next the project 
name of the file reference model is tagged to this tempfile as a UML model name (block 60) "). 
and (see Column 6, Lines 25-33, "Next, an inquiry (block 55) is made to determine whether or 
not there are any more screen specifications in the file reference model of the sub-project. If the 
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answer to this inquiry is yes, then a return is made back to the block 53. On the other hand, if the 
answer to this inquiry is no, then the process illustration continues in FIG. 5B as denoted by a 
connector A "), "diamond 58" and "block 55" determine the minimal mutual ancestor, and 

- creating the Extensible Markup Language tags for the schema element down from 

the mutual ancestor, (see Stefaniak , Column 6, Lines 34-40, "This step is followed by the step 

of tagging the file reference sub-model name as a UML package name to the tempfile (block 
61). Next, each screen specification in the UML package created in the previous step is parsed 
(block 62). Subsequently for each screen name, a UML class tag is assigned (block 63). The 
process illustration continues as denoted by a connector C") 

Stefaniak and van Elkeren didn't explicitly disclose traverse the Extensible Markup 
Language tagged nodes for the current context up to the minimal mutual ancestor. However, 
Shanmugasundaram taught traversing the Extensible Markup Language tags for the current 
context up to the mutual ancestor (see page 5, left hand column last 2 lines to right hand 
column, lines 1-14, "Do a depth first traversal of the DTD graph, starting at the element node for 
which we are constructing relations. Each node is marked as "visited" the first time it is reached 
and is unmarked it once all its children have been traversed. If an unmarked node in the DTD 
graph is reached during depth first traversal, a new node bearing the same name is created in the 
element graph. In addition, a regular edge is created from the most recently created node in the 
element graph with the same name as the DFS parent of the current DTD node to the newly 
created node. If an attempt is made to traverse an already marked DTD node, then a backpointer 
edge is added from the most recently created node in the element graph to the most recently 
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created node in the element graph with the same name as the marked DTD node ."), and (see 
page 6, left hand column last 2 lines to right hand column first three lines, "Finally, of the 
mutually recursive elements all having indegree one (such as monograph and editor in Figure 8), 
one of them is made a separate relation. We can find such mutually recursive elements by 
looking for strongly connected components in the DTD graph."). Therefore, it would have been 
obvious to one of ordinary skill in the art at the time the invention was made to use traversed 
technique, as suggested by Sandhu, to construct DTD node. The modification would have been 
obvious because one of ordinary skill in the art would have been motivated to lookup node in 
DTD graph. 



40. The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. 

41. Title: System and method for translating to and from hierarchical information systems. 
USPN: 6,523,042. 

42. Title: Method for converting relational data into a structured document. USPN: 
6,604,100. 

43. Title: METHOD AND APPARATUS FOR PROCESSING MARKUP LANGUAGE 
SPECIFICATIONS FOR DATA AND METADATA USED INSIDE MULTIPLE RELATED 
INTERNET DOCUMENTS TO NAVIGATE, QUERY AND MANIPULATE INFORMATION 
FROM A PLURALITY OF OBJECT RELATIONAL DATABASES OVER THE WEB. USPN: 
6,418,448. 
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44. Title: Automated creation of an XML dialect and dynamic generation of a corresponding 
DTD. USPN: 6,519,617. 

45. Title: Market makers using documents for commerce in trading partner networks. USPN: 
6,125,391. 

46. Title: Automatic transmission of legacy system data. USPN: 5,857,194. 

47. Title: Communication schema of online system and method of ordering consumer 
product having specific configurations. USPN: 6,609,108. 

48. Ning J Q et al., "Automated support for legacy code understanding", ACM Press New 
York, NY, USA Pages: 50 - 57 Periodical-Issue- Article Year of Publication: 1994 
ISSN:0001-0782 

49. Sneed, H.M., "Generation of stateless components from procedural programs for reuse in 
a distributed system", Software Maintenance and Reengineering, 2000. Proceedings of the 
Fourth European , 29 Feb.-3 March 2000, Page(s): 183 -188 

50. O'Hare et al., "RE-Analyzer: From source code to structured analysis",IBM SYSTEMS 
Journal, VOL 33, NO 1, 1994Constraints-preserving Transformation from XML Document 
Type Definition to Relational Schema 

5 1 . Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Kuo-Liang J Tang whose telephone number is 703-305-4866. 
The examiner can normally be reached on M-F 8:30 to 5:00. 

52. If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Tuan Q Dam can be reached on 703-305-4552. 
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53. Any response to this action should be mailed to: 

Commissioner of Patents and Trademarks 
Washington, D.C. 20231 
or faxed to: 

(703) 872-9306, ( for formal communications intended for entry) 
or: (703) 872-9306 ( for informal or draft communications, please label 
"PROPOSED" or "DRAFT") 

54. Hand-delivered response should be brought to Crystal Park n, 2121 Crystal Drive, 
Arlington, VA. , 22202. 4 ,h Floor(Receptionist). 
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